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(57) Abstract: An apparatus for communicating 
health care data from a sender to a receiver is 
provided. The apparatus has a first computer 
system (10), a second computer system, and a rules 
engine. The first computer system (10) has health 
care data stored therein. The second computer 
system is in operable communication with, and 
is configured to extract the health care data from 
the first computer system (10). The rules engine 
normalizes the extracted health care data to a 
predefined format. The rules engine defines a 
plurality of health care data fields in the predefined 
format, as well as a plurality of relationships 
between fields of normalized data. 
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SYSTEM FOR COMMUNICATION OF HEALTH CARE DATA 

RELATED APPLICATION 

The present application is related to and claims priority to U.S. 
Provisional Patent Application Serial No. 60/239,860, filed October 11, 2000, entitled 
"Apparatus and Method for Establishing Connectivity." To the extent not included 
below, the subject matter disclosed in this application is hereby expressly 
incorporated into the present application. 



FIELD OF THE INVENTION 

The present invention relates generally to a computerized system that 
establishes connectivity between interested parties in the health care industry for the 
administration of health care services. More particularly, the present invention relates 
15 to a system for the normalization of health care data of various formats and 

exchanging the data in normalized form between insurers and participants, such as 
providers, patients, and employers. 

BACKGROUND AND SUMMARY 

20 Health care can be defined as an information industry; most of the time 

and money spent in procuring and delivering health care is spent creating, retrieving, 
or using information. Expenditures on health care information technology support, 
for example, have increased from about one billion dollars in 1990 to a projected $20 
billion in 2000. Yet, even with these investments, it is believed that almost half of all 

25 current health care expenditures continue to be for non-patient care activities; a major 
share of which is for non-automated information support. 

Resources having to be directed to non-patient care activities have 
been endemic in the health care industry since the 1960's. During the 1990 ! s, 
however, with the demise of Medicare Cost Reimbursement and the rise of managed 

30 care, there has been a major shift in attitude and focus among both physicians and 
patients. New rules now govern the delivery of medical care and the payment for 
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such care. Whether via preferred provider arrangements, capitation arrangements of 
endless variety, case management, or <c best practice" enforcement, determining what 
care is allowed, what will be paid by whom, and making sure that the appropriate 
information is submitted to ensure that the process works are now consuming a major 
5 share of both time and financial resources of insurers, providers, and patients. 

Health care participants, like providers and employers, regularly deal 
with a number of health care plans from various health insurers. These participants, 
however, can only obtain information from the insurance companies in limited ways, 
often making the acquisition of such information quite burdensome. Participants 

10 usually only have the telephone, fax, or letter available as a means of communication 
with the insurers. 

Particularly vexing is the timely availability of information from 
insurers regarding financial transactions, such as eligibility, claims, and benefits, and 
basic patient-related information, such as medical tests and prescriptions. For 

1 5 example, a provider may seek information from an insurer via a submission form or 
telephone call to that insurer. In many cases, however, such information is sought or 
received after the care has been delivered and the patient has left the provider's office. 
This may result in the delivery of services that are not authorized or covered by the 
patient's insurer, or may result in other consequences that might impact the type or 

20 cost of the services provided. 

Another reason for these difficulties is the recent expansion of the 
"payor" community. At one time, payors consisted of the government (both federal 
and state) and large insurance companies. Now, a complex array of self-insured 
plans, IDN's, IPA's, and PPO's, undertaking full or partial capitation, insurance 

25 carve-outs, and the like have radically increased the number of users of, and the need 
for, current information regarding insureds. Most of these entities, both small and 
large, do spend considerable sums on information systems. Yet, because of the extent 
of manual processing that exists despite these systems, costs per claim remain 
substantial. 

30 In addition, payors incur the wrath of their providers and patients by 

designing complex rules that are difficult or perceived as impossible to administer or 
follow. Though contrary to this perception, payors do have an interest in providing 
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timely information to providers, patients, employers, and other participants. Still, a 
significant percentage of a provider's claims are rejected often because they do not 
comply with all of the rules. These claims require resubmission, telephone calls, and 
other expensive manual interventions. The dollar costs for this current processing 
5 scheme are high. In fact, an entire clearinghouse industry has been developed to 

provide eligibility (but not benefits) verification services to providers for a fee. Many 
of the requested verifications, however, cannot be performed at all by such 
clearinghouses, and those that are performed are often unacceptably cumbersome and, 
thus, too expensive. 

10 Referral authorizations are often even more complex than claims and 

such authorization services are generally not available via traditional clearinghouses. 
Each time a provider writes a prescription, for example, it is written against a 
formulary specific to that patient's health care plan established by their insurer. 
Because there are so many formularies, drug prescriptions, too, are often rejected for 

15 payment, causing additional work for both the provider and the patient. Similarly, 
medical tests must be sent to laboratories contracted to support a particular plan, and 
are reimbursed only when matching complex medical necessity rules. 

Many providers do have practice management systems that track 
encounters and manages billing. None of these systems, however, have the 

20 sophistication to accomplish the task of providing all of the information from all the 
various health insurers in such a cogent form that can be useful to the provider. 

Not only providers, but patients, too, spend a majority of their time 
interacting with the health care system engaged in non-health care activities. This 
"wasted" time is virtually all related to scheduling appropriate interventions, to 

25 waiting for information or services, or to obtaining authorization, reimbursement, or 
other information for desired or required health care. 

The internet has emerged as a major source of health care information 
for the public. A substantial portion of internet users use it for health care information 
or management. Specifically, patients search the internet for medical information and 

30 answers related to their area of concern, In fact, it is becoming common for a patient 
to enter a physician's office armed with printouts and long lists of questions and 
recommendations from web pages on the internet. 
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Unfortunately, even with the connectivity the internet provides, 
information exchange between insurers and patients is lacking. Most of the 
information available to patients from their insurer is on an automated basis from 
databases related to either general health care literature or to specific normality 
5 support groups. A critical aspect of the patient's health care program, however, is not 
only knowledge of the normality or support groups, but also what their insurer's 
health care plan provides as treatment options for that normality, eligibility 
information, referral authorization, claim submission and payment, testing, and 
medications. As discussed, these functionalities are too complicated for the current 

10 system to handle in an automated environment. Personally-referenced information 
linked to an individual patient's provider and health care plan is generally unavailable, 
because that data exists in several databases often each in a different, incompatible 
format, requiring human intervention to extract and process the data. The patient's 
current solution is, thus, an endless number of telephone calls at a high cost in dollars, 

15 time, and frustration. 

A reason for such incompatibility is that each database served the 
individual needs of those using the data before such a time when connectivity between 
databases was a consideration. The consequence of having different databases of 
different formats is that it is not possible to provide a central repository of 

20 homogenized data readable by any variety of computers. It is this incompatibility that 
prevents wide spread connectivity between insurers and participants. 

Transliterating and interfacing programs are known in the art. 
Programs that take data in one format can be translated and read by a computer of a 
different format. Such transliterating, however, only shifts data from a field of an 

25 incompatible format to a target field of a new format. It cannot determine whether the 
data of the incompatible format is being transferred to the correct target field. 
Normalization or remodeling of the data not only transfers the data, but also 
determines the meaning of the data and puts that data in the correct field. 

It would, therefore, be beneficial to provide a system with which 

30 insurers may communicate with providers, patients, etc., to provide information about 
a particular health care plan either before, or contemporaneously with, the patient's 
visit to the provider, regardless the lack of compatibility of the databases. It would be 
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further beneficial if this system of communication spanned a variety of insurers so the 
provider, for example, may communicate with any plan in which the patient 
participates. It would also be beneficial for providers to have an automated system of 
determining eligibility and benefits, receiving authorizations and pre-certifications, 
5 submitting claims, obtaining reimbursements, and adjudicating claim problems 
through the normalization of data of the incompatible databases. 

Accordingly, an illustrative embodiment of the present disclosure 
provides an apparatus for communicating health care data from a sender to a receiver. 
The apparatus comprises a first computer system, a second computer system, and a 

10 rules engine. The first computer system having health care data stored therein. The 
second computer system is in operable communication with, and is configured to 
extract the health care data from the first computer system. The rules engine 
normalizes the extracted health care data to a predefined format. The rules engine 
defines a plurality of health care data fields in the predefined format, as well as a 

1 5 plurality of relationships between fields of normalized data. 

Further embodiments may include the first computer being a plurality 
of computers each having portions of the health care data stored thereon. The 
apparatus may also comprise a third computer system, in operable communication 
with, and configured to receive the normalized data from, the second computer 

20 system. The rules engine may determine whether the third computer is authorized to 
receive the health care data. 

Another illustrative embodiment provides a method for communicating 
health care data from one computer system to another. The method comprises the 
steps of storing health care data in a first computer system; extracting health care data 

25 from the first computer system and communicating the extracted data to a second 

computer system; normalizing the extracted data to a predefined format in accordance 
with a rules engine that defines a plurality of health care data fields in the predefined 
format and a plurality of relationships between fields of normalized data; and 
communicating the normalized data to a third computer system. . 

30 Further embodiments of the illustrative method may include the first 

computer system comprising a plurality of computers, wherein the storing step 
includes storing health care data in more than one of said computers. Also, the third 
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computer system comprises a plurality of computers. The health care data exists 
across a plurality of databases such that each of the plurality of databases are in 
operable communication with the second computer system. 

Another illustrative embodiment provides a system of exchanging 
5 health care data between a sender and a receiver The system comprises a sender 
computer, an intermediary computer, a rules engine and a receiver computer. The 
sender computer stores the health care data. The intermediary computer is in operable 
communication with the sender computer and is configured to extract the health care 
data. The extracted data is normalized to a predefined format, creating normalized 

10 data pursuant to a rules engine. The rules engine defines each field of the health care 
data and converts each field to a corresponding field in the predefined format. The 
rules engine also defines how the normalized data should relate to each other pursuant 
to predetermined instructions. The receiver computer is in operable communication 
with the intermediary computer. The receiver computer receives the normalized data 

1 5 subjected to the second rules engine. 

Further embodiments may include the sender computer being a 
plurality of computers each having portions of the health care data stored thereon. 
The rules engine may determine whether the receiver computer is authorized to 
receive the health care data. When the receiver is a health care provider, the 

20 normalized data exchanged between the sender and receiver may be chosen from a 
group comprising eligibilityftenefit display, member roster, claim submission, 
provider lookup, formulary lookup, diagnosis code lookup, procedure code lookup, 
access health plan information online, communicate with a health plan on-line, 
communicate with patients on-line, patient-centric view of data across several health 

25 plans, order generation and tracking, results review and release, result printing, 

prescription writing, medication profile for each patient, access to patient's personal 
health record based on patient approval, personalized medical and health care content 
integration, both context-specific and on demand, e-commerce integration: office, 
medical and health-related product awareness and buying capabilities, email, practice 

30 management system subscription, support disease management, and physician 

credentialing subscription. When the receiver is an employer, the normalized data 
exchanged between the sender and receiver is chosen from a group comprising group 
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eligibility, group enrollment, enrollment changes, formulary lookup, e-commerce 
integration, access from health plan web site or direct access via URL, personalized 
content integration, both context-specific and on demand, e-commerce integration and 
health care-related product awareness and buying capabilities. 
5 When the receiver is a patient, the normalized data exchanged between 

the sender and receiver is chosen from a group comprising identification card 
requests, address changes, provider directory inquiries, personalized health 
information based on an interest profile, diagnosis information, relevant articles and 
patient education materials, communications from health care providers and health 

10 care plans, lab and radiology results, scheduled appointments with a health care 

provider, prescription refills, personal health records, eligibility/benefit information, 
claim information, referral and authorization information and status, provider lookup, 
family history, medication profile and formulary lookup. 

Another illustrative embodiment of the present invention provides a 

1 5 system of normalizing health care data for transfer between an insurer and a 

participant. The system comprises an insurer system, an intermediary system, and a 
participant system. The insurer system is configured to maintain at least one database 
comprising the health care data. The intermediary system is operatively connected to 
the insurer system and to the database, configured to extract the health care data from 

20 the database of the insurer system, and store the health care data in a staging database 
as extracted data. The extracted data is normalized to a predefined format, creating 
normalized data pursuant to a rules engine that defines each field of the extracted data 
in the predefined format. The rules engine also defines how the normalized data 
relates to each other pursuant to predetermined instructions. The participant system is 

25 in operable communication with the intermediary system, and is configured tqreceive 
the normalized data subject to the rules engine. 

Further embodiments of the illustrative system may include the at least 
one database being a plurality of databases, such that the intermediary system is 
operatively connected to the plurality of databases. In addition, the participant system 

30 may transmit a request that is sent to the intermediary system that determines which 
health care data is to be extracted and normalized in order to respond to the request. 
The participant system may also transmit the request, and the intermediary system 
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may transmit the normalized data over the internet. The rules engine may define the 
relationships among the normalized data pursuant to predetermined instructions to 
determine a response to the request. The intermediary system may also comprise an 
. error data system that removes extracted data identified as invalid when the extracted 
5 data is normalized. The extracted data identified as invalid is then corrected, 

reintroduced, and is normalized. The intermediary system may further comprise an 
audit database to track the activity of the intermediary system. 

Another illustrative embodiment of the present invention provides a 
system of health care management of medical testing administration between an 

10 insurer, a medical laboratory, and at least one health care participant. The system 
comprises a participant computer, an insurer processing system, a rules database, and 
a laboratory computer. A medical test request is made at the participant computer 
pursuant to a first predetermined format. The insurer processing system is operatively 
coupled to the participant's computer, and is through which the medical request is 

15 transferred. The processing system is operatively coupled to the rules database to 
approve the medical test request pursuant to predetermined criteria. The laboratory 
computer is operatively coupled to the processing system and receives the medical 
test request if approved by the rules engine. Results of the medical test are 
transmitted from the laboratory computer to the processing system. The results are 

20 further transmitted to an insurer computer that is operatively coupled to the laboratory 
computer and to participant's computer. 

Further embodiments of the illustrative system may include the 
processing system converting the results of the medical test to a second predetermined 
format readable by a database stored on the insurer computer. In addition, at least 

25 one health care participant may be chosen from a group comprising from a health care 
provider, an employer, and a patient. Furthermore, the medical test request and the 
results of the medical test may be transmitted through the internet. 

Additional features and advantages of the system will become apparent 
to those skilled in the art upon consideration of the following detailed descriptions 

30 exemplifying the best mode of carrying out the system as presently perceived. 
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BRBEF DESCRIPTION OF THE DRAWINGS 

The illustrative system will be described hereinafter with reference to 
the attached drawings which are given as non-limiting examples only, in which: 

Figure 1 is a diagrammatic view of a system for normalization of 
5 health care data and the exchange of same between several health care insurers and 
various health care participants; 

Figure 2 is a diagrammatic view of the data processing system for the 
system of normalization shown in Fig. 1 ; 

Figure 3 is a diagrammatic view of the data extraction and business 
10 object sub-systems for the system of normalization shown in Fig. 1 ; and 

Figure 4 is a diagrammatic view of a system of health care 
management for medical testing between health care insurers and participants. 

Corresponding reference characters indicate corresponding parts 
throughout the several views. The exemplification set out herein illustrates an 
1 5 embodiment of the invention, and such exemplification is not to be construed as 
limiting the scope of the invention in any maimer. 

DETAILED DESCRIPTION OF THE DRAWINGS 

An illustrative embodiment of the invention, such as that shown in Fig. 

20 1 , comprises a system 2 which includes a plurality of database sets 4, 6, 8 offered by a 
variety of insurers 11. It is appreciated that each health care database set 4, 6, 8 
represents an insurer's database processing system or series of processing systems and 
databases. For example, database sets 4, 6, or 8 may each represent a conventional 
computer system, a server, a local area network (LAN), a legacy, or other computer 

25 system storing one or more databases. It is contemplated that to transmit data, either 
the system as it exists is capable of doing so, or a system is added to either database 
sets 4, 6, or 8 to perform this function. It is further contemplated that each of database 
sets 4, 6, 8 may represent a single database or a plurality of databases, each of which 
may be of any variety of database formats or languages. 

30 For the purposes of this application, it is contemplated that reference to 

the term "insurer," as used herein for insurers 1 1, is for illustrative purposes only. 
Such a term includes health insurance companies, but also includes health 
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maintenance organizations, self-insured entities, disease management organizations, 
capitated health care providers, Medicare agencies, as well as any other organization 
that might store or manage health care data. The term "insurer" is not to be construed 
as being limited in scope to only health insurance companies or other '^payors." 
5 Conventionally, health care data is stored on an insurers 5 computer or 

series of computers in several databases, each of which often being in a unique 
format, with each database format being incompatible with other database formats. 
For example, one insurer may have their health care data stored in one format, and a 
second insurer may have their health care-related data stored in a second format that is 

1 0 not compatible with the one format. Additionally, and more problematic is that, even 
within the same insurer's 1 1 system, eligibility data, for example, may exist in a 
database of one particular format, developed to suit the needs of its users at the time, 
whereas, the claims data, for example, may be stored in another database in a format 
that suits the needs of those users, but with its format being incompatible with the 

1 5 fonnat of the eligibility data. In either example, it is contemplated that in the present 
invention, health care data of any format is normalized into a common format, and 
distributed through a common network, like internet 12, to a health care participant 
13, who uses the normalized data to conduct health care-related transactions and 
tasks. It is further contemplated, and to be discussed further herein, that various levels 

20 of access and security can be provided to assure that those participants 1 3 accessing 
the normalized data are authorized to access only that data predetermined as necessary 
and appropriate for their particular use or need. 

As Fig. 1 shows, data from each database set 4, 6, 8 can be transmitted 
to a data processing system 10 that normalizes the data into a format readable by 

25 particular health care participants 13. More specifically, the data is transmitted over 
the internet 12, which is operatively connected to and read by participants' 13 
computers) or terminal(s). Such participants 13 illustratively include providers 14, 
employers 16, and patients 18, or any combination thereof. It is contemplated that 
participants 13 can further include any other interested party that can request data or 

30 information from an insurer, including other insurers and disease management 
organizations, for example. 
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It is contemplated that the transmission of data from database sets 4, 6, 
or 8 is initiated by any of the participants 13 submitting a request 22 through a 
computer or computers. Request 22 is transmitted through the internet 12 to data 
processing system 10 which retrieves the appropriate data from the appropriate 

5 database set or sets of either 4, 6, or 8. That data is normalized to a common format, 
at which point a response 24 to the request 22 is made. For example, a health care 
provider 14 may place a request 22 on behalf of an insured to authorize payment for a 
medical procedure. In this example, it is presumed that the data required to formulate 
a response 24 exists collectively on eligibility, benefits, and claims databases that 

10 illustratively exist on database set 4. Data processing system 10, in order to prepare a 
response 24, determines and extracts which data is necessary from the databases. 
System 10 then normalizes the data into a homogenous format, and then determines 
what the nature of the response should be. In this example, response 24 should be to 
either authorize or deny payment for the medical procedure. System 10 uses the 

1 5 normalized data to determine the response, which is then transmitted to provider 1 4, 
thus, completing the transaction. It is contemplated that system 2 may comprise any 
number of insurers 11 or participants 13. Specifically, data processing system 10, as 
will be discussed further herein, is able to connect and manage transactions between a 
single or plurality of participants 1 3 with any insurer or plurality of insurers 1 1 . 

20 It is further contemplated that system 2 will provide health care 

participants 13 with a variety of health care transaction options referred to generally in 
the form of requests 22 and responses 24 between participants 13 and insurers 11. 
Examples of transactions available to health care providers 14 are: eligibility^enefit 
display, member roster, claim submission, provider lookup, formulary lookup, 

25 diagnosis code lookup, procedure code lookup, access health plan information online, 
communicate with a health plan on-line, communicate with patients on-line, patient- 
centric view of data across several health plans, order generation and tracking, results 
review and release, result printing, prescription writing, medication profile for each 
patient, access to patient's personal health record based on patient approval, 

30 personalized medical and health care content integration, both context-specific and on 
demand, e-commerce integration; office, medical and health-related product 
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awareness and buying capabilities, email, practice management system subscription, 
support disease management, and physician credentialing subscription. 

As further example, the following are specific records and fields for 
health care transactions between providers 14 and insurers 1 1 that utilize normalized 
5 data: 

Record: Summary 

Fields: 

10 Activity for (date) 

Referrals 
Claims 
Test Results 
Members 

1 5 Update State for Americas Health 

Benefit Records 

Claim Records 

Patient Records 

Provider Records 
20 New Just For You 

Record: Eligibility 

Fields: 

25 

Today's Patients 
Patient Search 
Sex 

Coordination of benefits 
30 Medicare data 

Add to patient list 

Name 

From Date 

To Date 
35 Birth date 

Member ID 

Relation 

PCP 

Address 
40 City 

State 

Zip 

Current Benefit 
Group 

45 Carrier 
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BenefitPlan 
Record: Claim Status 
5 Fields: 

Patient Name 
From Date 
To Date 

10 Claims 

Claim Number 
Status 

Provider Name 
Patient Name 
1 5 Member Number 

Billed Amount 
Patient Responsibility 
Paid Amount 
Date of Service 

20 

Record: Claim Detail 
Fields: 

25 Member 

Provider 

Diagnosis 

Description 

Line number 
30 DOS 

CPT 

Description 
Modifier 
Location 
35 Units 
Status 
Billed 
Allowed 
Copay 

40 Coinsurance 
Deductible 
Paid 
Totals 

45 Record: Explanation of Payments 
Fields: 
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Line Number 
Status Description 
Explanation 
Check/Date 



Record: Select Specialist 
Fields: 



10 



Address 
City, State, Zip 
Handicap Access 
Office Hours 
15 Contact 
Phone 
Fax Phone 
Phone After Hours 
Sex 

20 Birth Date 

Specialty 
Second Specialty 
Accept Patient 
Primary Care 

25 Board Cert 

Languages 
Hospitals 

Hospital Privileges 
Networks 

30 

Record: Add Claims 
Fields: 

35 Health Insurance 

Insured's ID Number 
Patient Last Name 
First Name 
Middle Name 

40 Patient's Address 1 

Address 2 
City 
State 
Zip 

45 Patient's Phone 

Birth date 
Gender 
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Relationship to Insured 

Marital Status 

Patient Employment Status 

Condition Related to Job 

Con. Rel. to Auto Accident 

Cond. Rel. to Other Accident 

Insured's Last Name 

First Name 

Middle Name 

Gender 

Birth date 

Insured's Address 1 

Address 2 

City 

State 

Zip 

Phone 

Insured' s Group or FECA Number 
Insured's Employer/School 
Insured's Insurance Name 
Referring Physician Name 
Referring Physician ID 
Outside lab 
Outside Lab Charges 
Medicaid Resub Code 
Medicaid Orig. 
Prior Auth. Number 
Diag Codes 
Item 

Date From 

Date To 

Place 

Type 

Procedure 

Modi 

Mod2 

DXInd. 

Charges 

Days/Units 

Patient 

Provider 

From Date 

To Date 

Diagnosis 1 

Diagnosis 2 

Diagnosis 3 

Diagnosis 4 
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Procedure Line 
CPT 

Description 
Amount 
5 Dx pointer 

Other Errors 
Total Amount 
Billed 

Allowed Amount 
10 Copay Amount 

Withheld Amount 
Writeoff Amount 
Predicted Payment 

15 Record: Referral Status „ 

Fields: 

Referral Number 
20 Patient (Member ID) 

Valid from (months) 
Referred by 
Referred to 
Patient List 
25 Referred by 

Referred to 
Referral Number 
Status 

30 Record: Add Referrals 
Fields: 

Today's Patients 
35 Patient Search 

Specialists 

Specialist Search 

Providers 

Diagnosis 
40 Patient 

Specialists 

Provider 

Diagnosis 

Start Date 
45 Months Valid 

Visits Requested 

Reason 
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Record: Procedure and Diagnosis Data 
Fields: 

5 

Diag Number 
Diagnosis Name 
Proc Code 
Procedure Name 
10 Visits Allowed 

Patient 

Patient Search 
Referred to 
Specialist Search 

15 Referred by- 

Diagnosis 
Start Date 
Exp Date 
Visits Requested 

20 Remarks 

Services Requested 
Authorized Ancillary Services 

Record: Diagnosis Codes 

25 

Fields: 

Diagnosis Code 
DX Code 

30 Diagnosis Code Description 

Record: Procedure Codes 
Fields: 

35 

Procedure Codes 
Procedure Code 
Procedure Description 
Age From 
40 Age To 

Sex 

Location Code 
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Record: Drag Therapeutic Class Listing 
Fields: 

Therapeutic Class 
Class Description 
Count of Drugs in this Class 

Record: Formulary List by Therapeutic Class 

Fields: 



Drug Name 
Generic Name 
15 Drug Class 

Therapeutic Class 
NDC 



Record: Write Prescription 
Fields: 



Today's Patients 
Patient Search 
25 Providers 
For 

Medication 

Dispense 

Refill 

30 Sig: Take 

Sig: For 
Instructions 
Select Pharmacy 

35 Record: Medication Profile 

Fields: 

Type 

40 Medication 
Dose 

Frequency 

Reason 

Status 



Record: Discontinued Medications 
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Fields: 

Type 

Medication 
5 Dose 

Frequency 

Reason 

Status 

10 Record: Allergies 

Allergen 
Reaction 
Date Started 

15 

Record: Medical Test Orders 
Fields: 

20 Patient ID 

Patient Name 

Provide ID 

Provider Name 

Location 
25 Lab Name 

Dx 

Action 
Battery 
Test 

30 ID 

Type 
Volume 
Date 
Time 

35 Collected By 

Chemistry 
Hematology 

Toxicology/Therapeutics 
Microbiology/Virology 
40 Immunology/Serology 
Urinalysis/Fluids 
Procedure 
When 
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Priority 

Specimen 

Alert 

5 Record: Results 
Fields: 

Status 

10 Order number 

Test Procedure 
Alert 

Order Date 
Facility 

15 Patient 
Provider 
Date/Time 
Procedure 
Status 

20 Indicator 
Date/Time 
Performed 
Specimen Number 
Type 

25 Status 
Result 
Value 

Desired Range 

30 Each field listed above represents data that can exist anywhere on 

database sets 4, 6, or 8, and be in any format or language. If any request 22 is made 
which calls up one or more of the above records, data processing system 10 searches, 
extracts, and normalizes the data so it appears in the correct field in the record. It is 
appreciated that provider 14 may change the data, if necessary, and transmit it back 

35 through internet 12 and data processing system 10 to be stored on the appropriate 
database set 4, 6, or 8. 

Examples of transactions available to employers 16 are: group 
eligibility, group enrollment, enrollment changes, formulary lookup, e-commerce 
integration, access from health plan web site or direct access via URL, personalized 

40 content integration, both context-specific and on demand, e-commerce integration: 
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human resource, business (e.g., office supplies) and health care-related product 
awareness and buying capabilities. 

Again, as a further example, the following are specific records and 
fields for health care transactions between employers 16 and insurers 1 1 that utilize 
5 normalized data: 

Record: Open Enrollment 

Fields: 

1 0 Health Insurance 

Employer Group Number 

Last Name 

First Name 

Middle Name 
15 Employee Address 1 

Address 2 
• City 

State 

Zip 

20 Home Phone 

Work Phone 
Primary Language 
Birth date 
Gender 

25 Social Security Number 

Primary Care Physician 

Established Patient 

Dependent Last Name 

First Name 
30 Middle Initial 

Birth date 

Gender 

Relationship 

Social Security Number 
3 5 Primary Care Physician 

Established Patient 

Effective Date 

Hire/Rehire Date 

Other Health Care Policy 
40 Name and Address of Insurer 

Effective date of other coverage 

Policy Holder's Last Name 

First Name 

Middle Name 
45 Policy/Group Number 
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Covered by Medicare 
Medicare Number(s) 

Health insurance within the last 1 8 months 
If yes, type of coverage: group, individual, COBRA, 
5 Medicare/Champus, Conversion or Other 

Reason coverage was terminated 
Read and Agree to Authorization Statement 

Record: Enrollment - Changes 

10 

Fields: 



Health Insurance 

Employer Group Number 
15 Last Name 

First Name 

Middle Name 

Employee Address 1 

Address 2 
20 City 

State 

Zip 

Home Phone 
Work Phone 
25 Primary Language 

Birth date 
Gender 

Social Security Number 
Primary Care Physician 

30 Established Patient 

Term Member 
Dependent Last Name 
First Name 
Middle Initial 

35 Birth date 

Gender 
Relationship 
Social Security Number 
Primary Care Physician 

40 Term Dependent 

Hire/Rehire Date 
Effective Date 
Change Reason 
Name 

45 Enrollment Type 

Remarks 
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Examples of transactions available to patients 18 are: identification 
card requests, address changes, provider directory inquiries, and personalized health 
information based on the member's interest profile, as well as diagnosis information 
from health plan administrative and clinical information, relevant articles and patient 
5 education materials, communications from health care providers and health care 
plans, lab and radiology results to patients online, scheduled appointments with a 
health care provider, referral status, prescription refills, education materials, personal 
health records so it can be maintained in his or her comprehensive health history 
online for physician reference, view eligibility/benefit information, view claim 

10 information, view referral and authorization information, provider lookup, personal 
health record, family history, medication profile, formulary lookup, and 
communications between member and provider. 

The architecture of the data processing system 10 is shown in Fig. 2. 
Each of the database sets 4, 6, 8 is operatively connected to data connectivity sub- 

15 system 20. The data connectivity sub-system 20 is configured to receive the different 
types of connections used between the various computer systems which store the 
database sets 4, 6, 8. It is appreciated that, in other embodiments, a separate data 
processing system 10 may be provided at the site of each of the database sets 4, 6, 8 
such that each data processing system 10 is dedicated to manage and normalize the 

20 data, as discussed further herein, as well as manage server-to-server communications 
for a single database set. 

The data extraction sub-system 28 is also depicted in Fig. 2. Sub- 
system 28 manages the integration of the often plurality of databases. The data 
extraction sub-system 28, as further discussed in reference to Fig. 3, also includes 

25 logic to manage data access from the several databases of database sets 4, 6, 8. An 
enterprise master person index ("EMPI") 30 is operatively coupled to data extraction 
sub-system 28. The EMPI 30 presents a cross-database view of all the insureds 
within system 2. It also manages the proper identification of providers 14, employers 
16, connected patients 18, as well as other entities having unique identities on an as- 

30 needed basis. An indices database 32 is supported by EMPI 30. Specifically, the 

indices database 32 stores indices which serve as a basis for relating the identification 
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data to each other. The indices database 32 is typically built upon and maintained by 
theEMPI30. 

The business object sub-system 34 contains the logic rules that drives 
the normalization of data and use of same between insurers 1 1 and participants 13. 

5 To provide such capabilities, a variety of processes may be supported in any particular 
situation. Dlustratively, such processes may include, but are not limited to, rules- 
based evaluation of entered data for referral authorizations and admission pre- 
certifications; proxy or actual adjudication of claims submitted by providers, with 
concomitant delivery of funds to insurers 11 and benefits explanations to patients 18; 

10 sorted lists of providers 14, employers 16, and patients 18; and graphical displays of 
laboratory results and integrated claims-driven health records for patients 1 8. 

The content/e-commerce sub-system 36 adds third party capabilities to 
the data processing system 10. The content portion of sub-system 36 provides 
management and integration of third party affiliated content, such as articles about 

1 5 diseases, bulletins, notices, notes, and other medically-related references. The e- 
commerce portion of sub-system 36 integrates e-commerce capabilities, including 
business-to-business or business-to-consumer purchasing through shopping cart-type 
databases with affiliated product and service vendors. 

The personalization sub-system 38 integrates information from the 

20 previous sub-systems 20, 28, 34, 36 to provide a personalized view of data in system 
2. Specifically, when any of the participants 13 login to system 2 and access data or 
other information from database sets 4, 6, or 8, or even the content/e-commerce sub- 
system 36, pertinent information derived from the type of content viewed, as well as 
the products purchased or searched, is maintained in a user profile database 40. 

25 During subsequent logins, therefore, the information a particular user views can be 
arranged and accessed in a more familiar, relevant, and useful manner, individual to 
that participant. 

The presentation sub-system 42 manages the normalized data and 
infonnation into a presentable format for participants 13. For example, the world- 
30 wide-web, being a popular destination for users of the internet, accepts output in 

HTML format, and is accessible by a conventional internet browser/ It is appreciated, 
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however, that such data may be presented in virtually any form to accommodate 
different access devices (for example, WAP for mobile devices). 

A security sub-system 44 is shown in Fig. 2 integrated with the other 
sub-systems 20, 28, 34, 36, 38, 42. Security sub-system 44 maintains data security in 
5 several ways. First, one embodiment contemplates that the insurers' 1 1 data is 

maintained on its own on-site database, and is controlled by the insurers 1 1 . Second, 
the insurers' 1 1 data is encrypted when it is routed from the insurers' 1 1 database to 
the connectivity sub-system 20 and, ultimately, the participants 13 when a request 22 
is made. Third, the participants' 13 browser includes encryption to view or send data 

10 over the internet 12. Finally, internal security is built into the data processing system 
10 to only allow users with need-to-know access to particular data, such as claims and 
referral information. For example, providers 14 may have access only to claims and 
referral information of their insurers, but not individual claim summaries of their 
patients. Similarly, the employers 16 may have access to only their employees' 

15 claims information, but not some personal information. 

An example of an encryption method is the 128 bit Secure Sockets 
Layer (SSL) with a key certified by VeriSign, Inc. Such SSL encryption means that 
data traveling through the internet and to participants' 13 browser cannot be 
interpreted by anyone between those two locations. Encryption is also useful because 

20 of the storage of user passwords. There is no place that a user's password is saved or 
used by the system as traditional cleartext. From one of the participants' 13 browser 
through internet 12 and to one of the insurers' 1 1 computer or server, the password is 
protected by SSL. Once the password reaches the final destined server, a 
cryptographic algorithm converts the password to a protected format. No one, 

25 therefore, who has privileged access to the server or any of the back-end applications 
can get any user passwords. 

In addition, encryption is useful along the operative connection to an 
insurer's 1 1 database sets 4, 6, or 8 to the data processing system 10. It is 
contemplated, however, that insurers' 1 1 computers or servers (database sets 4, 6, or 

30 8) may not need such encryption along this operative connection, if the connection is 
a true point-to-point connection. Also, this encryption can be implemented through 
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hardware or software, a virtual private network (VPN), or through the use of 
encryption protocols in a database, for example. 

There are several modes with which data can be restricted, even within 
and among the insurers 11 and participants 13 of system 2. For example, security 
5 sub-system 44 may restrict the actual data that a participant 1 3 may request or view 
from any of insurers 11. A health care organization, thus, may only view data that 
they have provided. For example, doctors may only view claim data for their own 
patients. Alternatively, security sub-system 44 may restrict access to participants 13 
to allow access to only particular fields on a particular screen of any particular 

10 database. For example, if a screen listed dollar amounts for claims, employers may 
wish to restrict who is able to view those dollar amounts. Other users, therefore, like 
patients 18, might be able to see the rest of the claims, but not the dollar amounts. 
Still, further, security sub-system 44 may restrict which screens will be accessible to 
which users. This level of security defines which functionality is available to the user. 

1 5 For example, a patient 1 8 in system 2 may not be able to view the claim submittal 

screen submitted by provider 14 at all, but may view a diagnosis information or health 
plan administrative screen. Customizable security based on the interests of the user 
may be included as well. This security method allows either the insurers 1 1 or 
participants 13 to set the parameters of security for the examples described above. It 

20 is further contemplated that this tool may be an internet-based tool that could add 
logins to the system, as well as specify values and screens that a particular user has 
access to. It is still further contemplated that a portion or all of the security measures 
can be employed throughout data processing system 12. 

An audit sub-system 46, like security sub-system 44, shown in Fig. 2, 

25 is also integrated with the other sub-systems 20, 28, 34, 36, 38, 42. Audit sub-system 
46 tracks the operation of all sub-systems. The information generated from audit sub- 
system 46 allows an administrator to monitor the operation of system 2 for problems 
and marketing trends. 

A diagrammatic view of the data extraction and business object sub- 

30 systems 28, 34, respectively, is shown in Fig. 3. As previously discussed, the 

numerous databases represented by database sets 4, 6, 8 contain data in a variety of 
formats. Before the data is transferred to one of the participants 13, however, it is first 
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fonnatted to a new format that is readable by any of the computers of participants 13, 
like HTML format, for example. The data is, therefore, "extracted" from the database 
sets, either 4, 6, or 8, and then "normalized" to be read by the computers of 
participants 13. The extracted data is indicated by reference numeral 48. 
5 Extracted data 48 from either database sets 4, 6, or 8 is uploaded to a 

staging database 50 which is typically a portion of data extraction sub-system 28. 
Rules engine 52 serves a dual purpose of defining the rules that control the 
normalization of the data, as well as how the data, once normalized, is used. During 
the normalization process at 54, rules engine 52 homogenizes the data by determining 

1 0 what the data means, then inserting the data into the proper field as normalized data. 
Rules engine 52 also remodels the data, if necessary, to a structure or appearance 
predefined by the normalized format. As a simple example, in a referrals database 
that may hypothetically exist on database set 6, it may include the entry "New Jersey" 
in the state location field. If that field is requested by a participant 13, the rules 

1 5 engine 52 will cause that field to be extracted, then determine whether the meaning of 
this field corresponds to the meaning of the normalized state location field, and, if so, 
then convert the field to the normalized state location field at 58. Furthermore, if the 
rules engine 52 has predetermined that the normalized state location field should exist 
as only a two-character acronym, then the phrase "New Jersey" will be remodeled to 

20 the acronym "NJ." This is contrasted with traditional transliterating programs that 
would merely match the state location field of the referrals database with any field in 
another database titled "state location field" and then transfer the data. Such a 
program cannot determine the meanings of the state location fields, and then 
determine if their meanings matched, as well as not remodel the data to the 

25 appropriate appearance. For example, a field for laboratory enzymes might be 
expressed in Celcius in one database and in Fahrenheit in another database. Such 
data, as well as countless other data, are typically contextualized by the system they 
exist in. Transliterating programs do not compensate for such context among data. In 
the present disclosure, part of the normalization is determining the meaning of the 

30 data and locating it in a field of the same definition, but in a single format. 

Rules engine 52 also determines whether the data is bad or invalid. 
Any bad or invalid data that is discovered during the normalization process at 54 is 
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transferred to an invalid data database 56. Invalid data is placed in database 56 for 
review and appropriate corrective action and, if appropriate, reintroduced and 
normalized. 

In addition, the rules engine 52 incorporates security 44 to determine 
5 whether the requestor has authorization to view the data that is being requested, as 
previously discussed. For example, if employer 16 requests claims data that 
illustratively exists on database set 8, the rules engine 52, in conjunction with the 
security 44, determines whether employer 16 has authorization to view the data 
subject of that request. If not, rules engine 52 would deny fulfillment of the request. 

10 Once the data is converted and remodeled into the normalized format, 

rules engine 52 determines how the normalized data can be used. For example, if a 
request 22 is made from providers 14 to one of the insurers 1 1 to authorize a chest X- 
ray for one of the patients 18, a proper response 24 may reference data from various 
eligibility, claims, benefits, and personal data databases which rules engine 52 first 

15 extracts and normalizes. Once the data is normalized, rules engine 52 undertakes the 
process of responding to request 22. Rules engine 52 bases response 24 on 
predetermined rules established by the particular insurer 1 1 to determine whether a 
chest x-ray is an approved procedure in response to the request. It is contemplated 
that each insurer 1 1, or even each database set 4, 6, 8 can be subject to its own unique 

20 set of rules to govern any particular response 24. 

An audit database 62, illustrated in Figure 3, manages and maintains 
tracking information during the conversion process at 58. All data requests, 
responses, and e-commerce submissions can be monitored and recorded. This audit 
trail information is maintained in audit database 62 to enhance performance and 

25 security characteristics. It is contemplated that audit database 62 can be integrated 
with audit sub-system 46, as shown in Fig. 2, or database 62 can be a stand-alone 
system working independently or in addition to sub-system 46. 

In one embodiment of the disclosure, it is contemplated that system 2 
will not only exchange information related to insurance and payment issues, but also 

30 provide active management of patient care. For example, as shown in Fig. 4, a 

portion of system 2 depicts the process for medical tests to be ordered, approved, and 
results submitted. For example, a health care provider 14, via the internet 12, places 
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an order for a medical test The order is transmitted through data processing system 
10. The order is further transmitted at 72 to a laboratory 70, the order will disclose 
particular information that will be needed when either the specimen or the patient 
arrives. If a specimen is collected by provider 14, the order will identify the 
5 laboratory 70, and provide information to provider 14 so that the specimen may be 
marked accordingly before being sent to laboratory 70. Once laboratory 70 receives 
the order and the specimen, laboratory 70 can either communicate the status or results 
back through data processing system 10 to both the provider 14 and the appropriate 
insurer 13', as indicated by reference numerals 74, 76, respectfully. 

10 Although the system has been described with reference to particular 

means, materials and embodiments, from the foregoing description, one skilled in the 
art can easily ascertain the essential characteristics of the illustrative system and 
various changes and modifications may be made to adapt the various uses and 
characteristics without departing from the spirit and scope of the present invention as 

1 5 described by the claims which follow. 



WO 02/31738 



PCT/US01/42618 



-30- 

What is claimed is: 

1 . Apparatus for communicating health care data from a sender to 
a receiver comprising: 

5 a first computer system having health care data stored therein; 

a second computer system in operable communication with, and 
configured to extract the health care data from the first computer system; and 
a rules engine to normalize the extracted health care data to a 
predefined format, said rules engine defining a plurality of health care data fields in 
10 the predefined format and a plurality of relationships between fields of normalized 
data. 

2. Apparatus of Claim 1, further comprising a third computer 
system, in operable communication with, and configured to receive the normalized 
data from, the second computer system. 

15 3 . The system of Claim 1 , wherein the first computer is a plurality 

of computers each having portions of the health care data stored thereon. 

4. The system of Claim 2, wherein the rules engine determines 
whether the third computer is authorized to receive the health care data. 

5. The system of Claim 1 , wherein the normalized data exchanged 
20 between the sender and receiver is chosen from a group comprising eligibility/benefit 

display, member roster, claim submission, provider lookup, formulary lookup, 
diagnosis code lookup, procedure code lookup, access health plan information online, 
communicate with a health plan on-line, communicate with patients on-line, patient- 
centric view of data across several health plans, order generation and tracking, results 

25 review and release, result printing, prescription writing, medication profile for each 
patient, access to patient's personal health record based on patient approval, 
personalized medical and health care content integration, both context-specific and on 
demand, e-commerce integration: office, medical and health-related product 
awareness and buying capabilities, email, practice management system subscription, 

30 support disease management, and physician credentialing subscription, wherein the 
receiver is a health care provider. 
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6. The system of Claim 1 , wherein the normalized data exchanged 
between the sender and receiver is chosen from a group comprising group eligibility, 
group enrollment, enrollment changes, formulary lookup, e-commerce integration, 
access from health plan web site or direct access via URL, personalized content 

5 integration, both context-specific and on demand, e-commerce integration and health 
care-related product awareness and buying capabilities, wherein the receiver is an 
employer. 

7. The system of Claim 1, wherein the normalized data exchanged 
between the sender and receiver is chosen from a group comprising identification card 

10 requests, address changes, provider directory inquiries, personalized health 

information based on an interest profile, diagnosis information, relevant articles and 
patient education materials, communications from health care providers and health 
care plans, lab and radiology results, scheduled appointments with a health care 
provider, prescription refills, personal health records, eligibility/benefit information, 

15 claim information, referral and authorization information and status, provider lookup, 
family history, medication profile and formulary lookup, wherein the receiver is a 
patient. 

8. A method for communicating health care data from one 
computer system to another, comprising the steps of: 

20 storing health care data in a first computer system; 

extracting health care data from the first computer system and 
communicating the extracted data to a second computer system; 

normalizing the extracted data to a predefined format in accordance 
with a rules engine that defines a plurality of health care data fields in the predefined 
25 format and a plurality of relationships between fields of normalized data; and 
communicating the normalized data to a third computer system. 

9. The method of Claim 8, wherein said first computer system 
comprises a plurality of computers, and wherein said storing step includes storing 
health care data in more than one of said computers. 

30 1 0. A method of Claim 8, wherein said third computer system 

comprises a plurality of computers. 
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1 1 . The method of Claim 8, wherein the health care data exists 
across a plurality of databases, each of the plurality of databases being in operable 
communication with the second computer system. 

12. A system of exchanging health care data between a sender and 
5 a receiver, the system comprising: 

a sender computer upon which health care data is stored; 

an intermediary computer in operable communication with the sender 

computer; 

wherein the intermediary computer is configured to extract the health 

10 care data; 

a rules engine configured to receive the extracted data and normalize 
same to a predefined format, said rules engine defines each field of the extracted data 
and converts each field to a corresponding field in the predefined format, creating 
normalized data, said rules engine also defines how the normalized data should relate 
15 to each other pursuant to predetermined instructions; and 

a receiver computer in operable communication with the intermediary 
computer and configured to receive the normalized data 

1 3 . The system of Claim 12, wherein sender computer is a plurality 
of computers each having portions of the health care data stored thereon. 

20 14. The system of Claim 12, wherein the rules engine determines 

whether the receiver computer is authorized to receive the health care data. 

15. The system of Claim 12, wherein the normalized data 
exchanged between the sender and receiver is chosen from a group comprising 
eligibility/benefit display, member roster, claim submission, provider lookup, 

25 formulary lookup, diagnosis code lookup, procedure code lookup, access health plan 
information online, communicate with a health plan on-line, communicate with 
patients on-line, patient-centric view of data across several health plans, order 
generation and tracking, results review and release, result printing, prescription 
writing, medication profile for each patient, access to patient's personal health record 

30 based on patient approval, personalized medical and health care content integration, 
both context-specific and on demand, e-commerce integration: office, medical and 
health-related product awareness and buying capabilities, email, practice management 
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system subscription, support disease management, and physician credentialing 
subscription, wherein the receiver is a health care provider. 

16. The system of Claim 12, wherein the normalized data 
exchanged between the sender and receiver is chosen from a group comprising group 
5 eligibility, group enrollment, enrollment changes, formulary lookup, e-commerce 
integration, access from health plan web site or direct access via URL, personalized 
content integration, both context-specific and on demand, e-commerce integration and 
health care-related product awareness and buying capabilities, wherein the receiver is 
an employer. 

10 17. The system of Claim 1 2, wherein the normalized data 

exchanged between the sender and receiver is chosen from a group comprising 
identification card requests, address changes, provider directory inquiries, 
personalized health information based on an interest profile, diagnosis information, 
relevant articles and patient education materials, communications from health care 
15 providers and health care plans, lab and radiology results, scheduled appointments 
with a health care provider, prescription refills, personal health records, 
eligibility/benefit information, claim information, referral and authorization 
information and status, provider lookup, family history, medication profile and 
formulary lookup, wherein the receiver is a patient. 
20 1 8 . A system of normalizing health care data for transfer between 

an insurer and a participant, the system comprising: 

an insurer system configured to maintain at least one database 
comprising the health care data; 

an intermediary system operatively connected to the insurer system 
25 and to the database; 

wherein the intermediary system is configured to extract the health 
care data from the database of the insurer system, and store the health care data in a 
staging database as extracted data; 

a rules engine configured to receive the extracted data and normalize 
30 same to a predefined format, said rules engine defines each field of the extracted data 
and converts each field to a corresponding field in the predefined format, creating 
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normalized data, said rules engine also defines how the normalized data should relate 
to each other pursuant to predetermined instructions; and 

a participant system in operable communication with the intermediary 

system; 

5 wherein the participant system is configured to receive the normalized 

data subject to the rules engine. 

19. The system of Claim 1 8, wherein the at least one database is a 
plurality of databases, wherein the intermediary system is operatively connected to the 
plurality of databases. 
10 20. The system of Claim 18, wherein the participant system 

transmits a request that is sent to the intermediary system that determines which 
health care data is to be extracted and normalized in order to respond to the request. 

2 1 . The system of Claim 20, wherein the participant system 
transmits the request and the intermediary system transmits the normalized data over 

15 the internet. 

22. The system of Claim 18, wherein the intermediary system 
comprises an error data system that removes extracted data identified as invalid when 
the extracted data is normalized. 

23. The system of Claim 22, wherein the extracted data identified 
20 as invalid is corrected and reintroduced and is normalized. 

24. The system of Claim 18, wherein the intermediary system 
comprises an audit database to track activity of the intermediary system. 

25. The system of Claim 20, wherein the rules engine defines the 
relationships among the normalized data pursuant to predetermined instructions to 

25 determine a response to the request. 

26. A system of health care management of medical testing 
administration between an insurer, a medical laboratory and at least one health care 
participant, the system comprising: 

a participant computer at which a medical test request is made pursuant 
30 to a first predefined format; 

an insurer processing system that is operatively coupled to the 
participant's computer, and through which the medical request is transferred; 
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wherein the processing system is operatively coupled to a rules 
database to approve the medical test request pursuant to predetermined criteria; and 

a laboratory computer operatively coupled to the processing system 
and receives the medical test request if approved by the rules engine; 
5 wherein results of a medical test are transmitted from the laboratory 

computer to the processing system where the results are transmitted to an insurer 
computer operatively coupled to the laboratory computer and to participant's 
computer. 

27. The system of Claim 26, wherein the processing system 

10 converts the results of the medical test to a second predefined format readable by a 
database stored on the insurer computer. 

28. The system of Claim 26, wherein the at least one health care 
participant is chosen from a group comprising from a health care provider, an 
employer, and a patient. 

15 29 . The system of Claim 26, wherein the medical test request and 

the results of the medical test is transmitted through the internet. 
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